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CONFIGURATION 



(54) PROCEDE DE CREATION DE FICHIERS DE CONFIGURATION D'OBJETS INCLUS DANS UN SYSTEME 
INFORMATIQUE. 

(57) L'invention a pour objet la creation d'au moins un fi- 
cmer de configuration d'au moins un objet materiel et/ ou lo- 
giciel comprenant des paramfctres, ledit fichier de 
configuration 6tant 6crit en utilisant un m6talangage de des- 
cription dont le format est ind6pendant du materiel et/ ou lo- 
giciel & configurer, ce fichier de configuration incluant tout 
ou partie des param&tres dudit objet et se reposant sur un 
fichier de description d6finissant des contraintes & respecter 
sur sa structure et sa syntaxe lors de son 6criture. L'inven- 
tion consiste, avant TScriture du fichier de configuration, 

- & etendre le fichier de description par au moins un mo- 
dule comprenant au moins un paramfctre dScrit dans le fi- 
chier de description, 

- et k valoriser tout ou partie des paramfctres de ce mo- 
dele. 
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ProcSdS de creation de fichiers de configuration d'objets inclus dans un 
systeme informatique. 

DESCRIPTION 
Domaine technique 

La presente invention se rapporte a un procede de creation de fichiers 
de configuration d'objets appartenant a un systeme informatique. 

Le systeme informatique comprend des objets materiels (machines, ...), 
et/ou logiciels (applications, ...). Ce systeme est indifferemment un systeme 
distribue ou non, heterogene ou non. 

Les objets comprennent des parametres inclus dans un fichier de 
configuration. L'invention s'applique a tout fichier de configuration ecrit dans un 
langage de balisage extensible, c'est-a-dire un langage qui presente de 
I'information encadree par des balises. Le fichier de configuration est ecrit en 
utilisant un metalangage de description dont le format est independant du 
materiel et/ou logiciel a configurer. Un metalangage se defini generalement 
comme etant un langage utilise pour decrire un autre langage. Le langage de 
balisage XML (extensible Markup Langage), connu de I'homme du metier, est 
bien adapte a la mise en ceuvre de la presente solution. Rappelons que la 
specification du langage XML est definie par le consortium W3C (World Wide 
Web Consortium). Ce consortium est un Organisme de promotion du «World 
Wide Web», qui met au point des normes et des protocoles ouverts et libres, 
dans un souci d'lnteroperabilite maximale. Le fichier de configuration XML a 
une structure declaree dans un fichier de description. Ce fichier de description 
comprend la description des parametres de configuration d'un objet et se 
nomme generalement Definition de Type de Document (DTD). Cette definition 
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s'effectue selon un formalisms particulier egalement defini dans la specification 
XML du consortium W3C. 



L'art anterieur 

Par definition, I'ecriture d'un fichier de configuration dans un langage 
XML doit obeir a certaines contraintes syntaxiques. En effet, un document XML 
a une structure logique. II se compose de descriptions, d'elements, de 
commentaires, d'appels de caractere et destructions de traitement, qui sont 
indiques dans le document par I'intermediaire d'un balisage explicite. Les 
elements sont encadrees par de balises ouvrantes, par exemple <preface>, et 
des balises fermantes, par exemple </preface>. Les elements sont structures et 
decrivent les parametres des objets. Les parametres, comme un attribut d'un 
objet, peuvent etre inclus a I'interieur meme des balises. Par exemple, on peut 
ecrire <LIVRE sujet = k> signifiant que I'attribut sujet de I'element LIVRE a la 
valeur K. 

Dans notre exemple de realisation, Les parametres des objets sont 
definis dans un fichier de configuration ecrit dans un langage XML tel que 
defini precedemment. 

Le probleme principal est que les objets a configurer se comptent en 
milliers et que plusieurs de ces objets peuvent se reposer sur un meme fichier 
de description DTD et avoir des valeurs identiques pour tout ou partie de leurs 
parametres. Pour construire le fichier de configuration, I'administrateur du 
systeme de gestion doit alors valoriser les parametres decrit dans le fichier de 
description autant de fois qu'il y a d'objets se reposant sur ce fichier DTD. Plus 
precisement, supposons que deux objets B1 et B2 se reposent sur un meme 
fichier de description (DTD). Pour configurer I'objet B1, I'utilisateur doit 
valoriser tous les parametres decrit dans le fichier DTD. Pour configurer I'objet 
B2, I'utilisateur doit a nouveau valoriser tous les parametres decrit dans le 
fichier DTD. En consequence, les parametres de meme valeur sont ecrit autant 
de fois qu'il y a d'objets se reposant sur un meme fichier de description. 
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L'ecriture d'un fichier de configuration presente done des redondances. Le 
langage XML etant un langage de configuration da bas niveau, un utilisateur 
est done contraint d'ecrire dans le fichier de configuration des descriptions de 
parametres repetitives dont la semantique est, dans certains cas, sans rapport 
avec ses besoins, ce qui necessite une culture importante de sa part de 
I'ensemble des syntaxes offertes par le langage XML. De ce fait, le fournisseur 
doit fournir avec le fichier de description une documentation precise. II est clair 
qu'un fichier de configuration impose un cout en temps important en ecriture. 

Un autre probleme, lie au nombre important d'objets a decrire, est que si 
un utilisateur situe sur une machine quelconque du reseau souhaite visualiser 
des ressources du systeme informatique configurees dans le fichier de 
configuration, le systeme de gestion doit alors transmettre le fichier de 
configuration a la machine distante par I'intermediaire du reseau. Lorsque le 
fichier de configuration a un gros volume, le flux de donnees entre le systeme 
de gestion et Implication cliente peut s'averer tres important et conduire a 
saturer le systeme de communication entre les applications clientes et le 
systeme de gestion. 

Enfin, un autre probleme est que la syntaxe definie selon les 
recommandations du consortium W3C doit etre respectee a la lettre tout au 
long de l'ecriture du fichier de configuration. Le risque d'erreur lors de l'ecriture 
d'un fichier de configuration est done permanent pour un administrates du 
systeme de gestion. 

Sommaire de I'invention 

Un premier but de la solution est done de simplifier considerablement 
l'ecriture des fichiers de configuration reduisant en consequence a la fois le 
cout en temps d'ecriture de celui-ci et le risque d'erreurs d'ecriture. 

Un deuxieme but vise est de reduire la taille du fichier de configuration. 

A cet effet, la solution a pour objet un precede de creation d'au moins un 
fichier de configuration d'objets materiels et/ou logiciels presents dans un 
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systeme informatique, ledit fichier de configuration etant ecrit en utilisant un 
metalangage de description dont le format est independent du materiel et/ou 
logiciel a configurer, ce fichier de configuration incluant tout ou partie des 
parametres desdits objets et se reposant sur un fichier de description 
definissant des contraintes a respecter sur la structure et la syntaxe lors de 
Tecriture dudit fichier de configuration, caracterise en ce qu'il consiste a 
etendre le fichier de description par au moins un modele comprenant au moins 
un parametre decrit dans le fichier de description, et en ce qu'il consiste a 
valoriser tout ou partie des parametres de ce modele. 

II en resulte egalement un fichier de configuration d'objets materiels 
et/ou logiciels presents dans un systeme informatique, ledit fichier de 
configuration etant ecrit en utilisant un metalangage de description dont le 
format est independant du materiel et/ou logiciel a configurer, ce fichier de 
configuration incluant tout ou partie des parametres desdits objets et se 
reposant sur un fichier de description definissant des contraintes a respecter 
sur la structure et la syntaxe lors de I'ecriture dudit fichier de configuration, 
caracterise en ce que le fichier de description est etendu, en ce que ('extension 
comprend au moins un modele incluant au moins un parametre inclus dans le 
fichier de description, et en ce que une partie des parametres de ce modele 
sont valorises. 

(-'invention sera mieux comprise a la lecture de la description qui suit, 
donnee a titre d'exemple et faite en reference aux dessins annexes. 

Description d'un exempie de realisation 

Dans les dessins - 

- la figure 1 est une vue synoptique de I'architecture d'un systeme 
informatique sur lequel peut s'appliquer la solution, 

- la figure 2, est une vue d'un modele conforme a la presente solution. 
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Sur la figure 1 , on a represents un systeme informatique SYS distribue 
illustrant un exemple de realisation prefere de la solution. Dans I'exemple 
illustre, ce systeme SYS inclut un systeme de gestion SG et au moins une 
machine Ml Le systeme de gestion SG comprend au moins un systeme 
Sexploitation, au moins une memoire de stockage d'informations et au moins 
un processeur controlant le processus du traitement de I'information. Le terme 
gestion est utilise pour etre conforme a la traduction Afnor (Association 
Francaise de NORmalisation) de « Management ». Un systeme de gestion de 
machines de type « Open Master » (marque deposee par la societe BULL 
S.A.), connu de I'homme du metier, est particulierement bien adapte pour la 
mise en oeuvre de la solution. Ce systeme de gestion peut etre assimile 3 un 
ensemble de services qui interagissent entre eux pour donner une 
representation objet du monde reel constitue notamment par les machines du 
systeme informatique. C'est une representation objet qu'un administrates 
manipule (surveillance, action) pour gerer le monde reel. La representation 
objet porte sur des objets virtuels du monde reel et constitue un modele objet. 
En d'autres mots, un objet gere par le systeme de gestion est une vue 
abstraite, definie pour les besoins de gestion, d'une ressource logique ou 
physique du systeme informatique. (disque, processeur, memoire, etc.) et/ou 
logiques (fichiers, processus, semaphores, etc.). 

Le systeme de gestion et les machines qu'il gere constitue une 
architecture Client/Serveur. Dans une telle architecture, un application cliente 
interroge le systeme de gestion pour connaitre I'etat des objets geres par le 
systeme de gestion. Le mode client/Serveur a I'avantage de permettre a un 
utilisateur appele client (ou application cliente) situe sur une machine, par 
exemple par I'intermediaire d*un simple micro-ordinateur ou d'une station de 
travail, de confier une partie de sa tache ou de ses operations a effectuer au 
serveur a savoir le systeme de gestion. De cette maniere, le client dispose 
d'une capacite de calcul beaucoup plus importante que celle de son micro- 
ordinateur. 
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Le systeme informatique peut etre heterogene. Afin de masquer 
I'heterogeneite du systeme informatique, le systeme de gestion SG et les 
machines gerees par le systeme de gestion comprennent au moins un agent 
respectif associe a un protocole de gestion. Un agent assure, entre autres, une 
5 conversion de protocole. 

Le systeme de gestion est relie a une machine geree par I'intermediaire 
d'un reseau quelconque. Le reseau peut etre de type LAN (Local Area 
Network), WAN (Wide Area Network). Un ensemble de couches logicielles 
s'interpose entre le systeme de gestion SG et le reseau RES et entre le reseau 
10 et chaque machine. Pour des raisons de simplification de la description, cet 
ensemble de couches logicielles n'est pas represents sur la figure 1 . 

Chaque objet gere comprend des parametres definis dans un fichier de 
configuration de preference ecrit dans un langage de description a balisage 
comportant une structure et incluant tout ou partie des parametres (nom, au 
is moins un attribut, au moins une action, etc.) des objets. Le fichier de 
configuration se base sur un fichier distinct appele fichier de description 
definissant les contraintes sur la structure et les contraintes syntaxiques des 
parametres pour I'ecriture dudit fichier de configuration associe a un objet 
d'une machine. De preference, le fichier de configuration est ecrit dans un 
20 langage de type XML, et le fichier de description est un fichier de description 
de type DTD, connus de I'homme du metier. Dans notre exemple de realisation, 
ce fichier de configuration XML et le fichier de description DTD sont inclus 
dans le systeme de gestion SG. 

Dans notre exemple de realisation, le fichier de description DTD est 
25 centralise sur le systeme de gestion de facon a etre utilisable par toutes les 
machines du reseau. De preference, les objets geres peuvent etre represents 
par un arbre, chaque noeud de I'arbre representant un objet gere. Une 
application de visualisation APV incluse sur la machine M1 peut interroger le 
fichier de configuration dans le but de recevoir les parametres des objets 
.10 configures et de visualiser ces objets sur cette machine. De preference, pour la 
visualisation des parametres de configuration des objets, la machine M1 est 
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munie d'un navigateur standard dit c Internet Explorer », connu de I'homme du 
metier, dans lequel un programme en langage JAVA est execute pour lire le 
fichier de configuration, accedant ainsi a son contenu et a sa structure, et pour 
transmettre les informations lues a (aux) applications de visualisation APV. 

Description de paramfetres H» configuration d'un objet ■ 

Un objet comprend comme parametre au moins un attribut. Par exemple, 
un attribut ID est Tidentificateur de I'objet, un autre attribut TYPE designe son 
type, et un autre attribut OWNER. De plus, un objet a des propriety. Dans 
notre exemple, un objet comprend egalement comme parametres: 

■ le nom de I'objet, 

■ les actions que I'on peut executer sur cet objet incluant Taction ouvrir 
pour I'ouverture du noeud, Taction fermer pour la fermeture du noeud, Taction 
developper pour visualiser les noeuds subordonnes a un noeud, 

■ et des proprietes graphiques de ce noeud incluant le type de police 
de caractere, I'adresse de Tic6ne qui lui est associe, et la couleur de fond 
desiree 

Ainsi, dans ce fichier de description DTD, un element « noeud » est 
associe a un noeud, et des elements lui sont subordonnes et sent associes 
respectivement 

■ au nom de I'objet 
aux actions (ouvrir, fermer, developper) que Ton peut executer sur cet 



■ 

objet, 



■ et aux proprietes graphiques (police de caractere, ic6ne, couleur de 
fond) de cet objet. 

Des attributs peuvent etre associe a un element. Dans notre exemple de 
realisation, Telement « noeud » comprend trois attributs a savoir : 

■ un attribut ID designant son identificateur 

■ un attribut TYPE designant son type 

■ et un attribut designant son proprietaire 
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Un fichier de description DTD definissant un objet de I'arbre peut etre 
ecrit de la facon suivante, en respectant le formalisme particulier defini dans la 
specification XML du consortium W3C : 

5 < ! ELEMENT noeud (noeudNom, noeudActions, 

noeudProprieteGraphique)> 

< ! ELEMENT noeudActions (action*)> 

< ELEMENT noeudNom (groupeNom, adresseNom, versionNom)> 
<!ATTLIST noeud Id CDATA # REQUIRED 
io Type CDATA #REQUIRED 

Owner CDATA #REQUIRED 

> 

< ! ELEMENT noeudProprietegraphique (police, icone, couleur)> 

is Dans ce fichier, CDATA #REQUIRED siginifie que I'attribut en question 

doit etre un bloc de texte contenant des caracteres. De plus, 1'ecriture 
« action* » signifie que les actions n'ont pas d'attributs et que la syntaxe de ces 
actions a utiliser lors de recriture du fichier de configuration est du texte. 

L'ecriture < ! ELEMENT noeudNom (groupeNom, adresseNom, 
20 versionNom)> indique que I'element « noeudNom » comprend trois elements 
(groupeNom, adresseNom, versionNom) qui lui sont subordonne. L'element 
« groupeNom » designe le nom de I'objet, I'element « adresseNom » designe 
I'adresse de I'objet, et I'element « versionNom » designe la version de I'objet. 
Ce fichier de description correspondra dans la suite de la description au 
25 fichier de description initialement cree. 

Notons que le nombre de parametres dans notre exemple de realisation 
est reduit pour des raisons de simplification de la description. En general un 
fichier de description comprend un nombre de parametres plus important. 

Dans I'exemple illustre, supposons par exemple que trois objets (OBJ1, 
30 OBJ2 et OBJ3) se reposent sur le meme fichier de description DTD defini plus 
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haut. Le probleme principal est que, pour construire le fichier de configuration, 
I'administrateur du systeme de gestion doit valoriser les parametres decrit dans 
le fichier de description autant de fois qu'il y a d'objets se reposant sur ce 
fichier DTD. L'administrateur doit done completer le fichier de configuration 
trois fois. Le cout en temps d'une telle ecriture est done considerable. 

A cet effet, la solution consiste a etendre le fichier de description par au 
moins un modele comprenant au moins un parametre inclus dans le fichier de 
description, et en ce qu'il consiste a valoriser une partie des parametres de ce 
modele d'element. En L'espece, la solution consiste a introduce un modele 
d'element dont I'ecriture respectent des proprietes definies dans ce qui suit. 

Dans notre exemple de realisation, nous avons a definir un ensemble 
d'objets dont les seuls parametres variant entre eux sont 

- I'element « Norn » correspondant au nom des objets (OBJ1, OBJ2 et 
OBJ3), respectivement (JAZZ, POP, SOL), 

- et I'attribut « ID » correspondant a I'identificateur des objets (OBJ1, 
OBJ2 et OBJ3), respectivement (123, 142, 162). 

Ces deux parametres seront dits indefinis dans le suite de la 
description. Dans I'exemple de realisation, les objets (OBJ1, OBJ2 et OBJ3) 
ont un nom respectif (JAZZ, POP, SOL) et un identificateur respectif (123, 142, 
162). 

Conformement a notre hypothese de depart, les autres parametres ont 
la meme valeur pour chaque objet (0BJ1, OBJ2 et OBJ3). lis seront dits 
definis. Ainsi, 

■ la valeur de I'element correspondant aux actions que Ton peut 
executer est la meme pour chaque objet (OBJ1, OBJ2 et 0BJ3), 

■ la valeur de I'element correspondant aux proprietes graphiques est la 
meme pour chaque objet (OBJ1, OBJ2 et OBJ3) , 

et la valeur des attributs 
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■ TYPE designant le type du objet est le meme pour chaque objet 
(0BJ1, OBJ2etOBJ3), 

■ et OWNER designant son proprietaire est le meme pour chaque objet 
(OBJ1, OBJ2 et OBJ3). 

Pour des raisons de simplification de la description, on donnera des 
valeurs arbitrages aux parametres definis. Dans notre exemple, la valeur de 
I'element correspondant aux actions que I'on peut executer sur chaque objet 
(OBJ1, OBJ2 et OBJ3) est ACT1 pour la commande « ouvrir », ACT2 pour la 
commande « fermer », et ACT3 pour la commande « developper ». De meme, 
la valeur de I'element correspondant aux proprietes graphiques de chaque 
objet (OBJ1, OBJ2 et OBJ3) est PR01 pour la police de caractere, PR02 pour 
I'icone, et PR03 pour la couleur de fond. Enfin, les attributs TYPE et OWNER 
prennent pour chaque objet (OBJ1, OBJ2 et OBJ3) respectivement les valeurs 
« snmp » et « operateur ». 

Les deux etapes principales du procede conforme a la solution sont 
respectivement 

- I'ecriture du fichier de description DTD et de I'extension associe a ce 
fichier constitue par au moins un modele d'element (etape 1), 

- et I'ecriture du fichier de configuration resultant de la valorisation des 
parametres indefinis du modele d'element (etape 2). 

Ecriture du fichier de descrip tion et introduction de la notion de 
modele d'element dan s un fichier de description ; 

La premiere etape doit realisee en respectant certaines proprietes. Les 
parametres de ces objets dont la valeur est invariante etant identifies, la 
solution consiste a introduire le modele d'element MODELE dans le fichier de 
description DTD cree. Le modele d'element se distingue des autres elements 
du fichier de description en ce sens qu'il comporte au moins un parametre avec 
une valeur. 
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Premierement, le module comprend, en respectant le formalisme 
d'ecriture d'un fichier de description DTD defini dans la specification XML du 
consortium W3C, 

- une entete MODELE avec un nom specifique « tnoeud » 

- et une reference a un element « noeud » defini du fichier de 
description DTD cree initialement 

Le modele MODELE peut etre ecrit de la facon suivante : 

< IMODELE tnoeud ELEMENT =noeud > 

signifiant que le modele MODELE a un nom specifique « tnoeud » et 
qu'il se base sur la description de I'element « noeud » defini au prealable dans 
le fichier de desciption (DTD). 

Deuxiemement, dans ce modele, I'ecriture des elements indefinis est 
particuliere. De facon a distinguer un element defini d'un element indefini dans 
le modele d'element, les elements a definir sont reperes dans ce modele par 
I'intermediaire d'une balise specifique dont I'entete est par exemple 
< !DEFINIR...>. De plus, les elements a definir sont identifies par un nom 
« tnoeudNom » et une reference a un element noeudNom du fichier de 
description initial precisant sur quel element du fichier de description 
prealablement defini se base le modele d'element « tnoeudNom ». Dans notre 
exemple, un element a definir peut s'ecrire de la facon suivante : 

< IDEFINIR tnoeudNom...ELEMENT noeudNom >. 

A la difference des elements indefinis, les elements definis du modele 
d'element sont ecrits de la meme facon que pour Tecriture d'un fichier de 
configuration XML. 

Troisiemement, I'ecriture des attributs indefinis respecte des proprietes. 
Dans ce modele, les attributs a definir et definis, la solution consiste a 
introduire deux mots cles DEFINIR et DEFINI indiquant qu'un parametre 
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attribut est a definir (DEFINIR) ou est defini (DEFINI). Dans notre exemple, 
I'attribut ID est a definir lors de I'ecriture du fichier de configuration, tandis que 
les attributs TYPE et OWNER sont definis et prennent respectivement les 
valeurs « snmp » et « operateur ». Dans notre exemple, la liste d'attributs est 
5 relative au modele d'element MODELE « tnoeud » et peut s'ecrire de la facon 
suivante : 

< ! ATTLIST tnoeud 
ID DEFINIR 

TYPE DEFINI « snmp » 

10 OWNER DEFINI « operateur » 

> 

En definitive, le fichier de description DTD qui decoule d'une telle 
configuration peut s'ecrire de la facon suivante : 

< IMODELE tnoeud ELEMENT=noeud 

is < IDEFINIR tnoeudNom ELEMENT=noeudNom> 

< noeudActions > 

<action nom=ouvrir> ACT1</action> 
<action nom=fermer>ACT2</action> 
<action nom=developper>ACT3</action> 
20 </ noeudActions > 

< noeudProprietesgraphiques > 

<police de caracteres PRO 1 ... /> 
<lcone>PR02</lcone> 
< couleur de fond PR03/> 
25 < / Proprietesgraphiques > 

> 

< I ATTLIST tnoeud 

ID DEFINIR 

TYPE DEFINI « snmp » 
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OWNER DEFINI « operateurw 

>. 

Ce fichier constitue un facteur commun FC pour I'ecriture du fichier de 
configuration et decrit les parametres (element et/ou attribut) a definir. 

5 

Ecriture du fichier de configuration 

La figure 2 est une vue du fichier de configuration qui resulte de 
I'utilisation du modele d'element. 

L'ecriture du fichier de configuration correspond a la deuxieme etape. 

jo Cette operation consiste a utiliser le modele d'element MODELE d<§fini dans le 
fichier de description DTD et a valoriser les Elements et attributs indSfinis. Lors 
de I'ecriture du fichier de configuration, la solution consiste a utiliser la partie 
comprenant les parametres valorises comme facteur commun, et en ce que 
I'ecriture se limite a la valorisation des parametres ne comportant pas de 

is valeur. 

En I'espece, trois objets (OBJ1, OBJ2 et OBJ3) ayant pour nom 
respectif (JAZZ, POP, SOL) et un identificateur respectif (123, 142, 162) sont a 
configurer et I'ecriture du fichier de configuration pour ces trois objets se limite 
a ecrire les trois blocs suivants (B1, B2 et B3) : 

20 (B1) 

< tnoeud ld= «123»> 
< tnoeudNom > 
<noeudNom> 

<groupeNom> JAZZ </groupeNom> 
25 <adresseNom> dbO </ adresseNom > 

<versionNom> 8.0 <versionNom> 
</noeudNom> 
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</ tnoeudNom > 
</tnoeud> 

(B2) 

< tnoeud ld= «142»> 

< tnoeudNom > 

<noeudNom> 

<groupeNom> POP </groupeNom> 
<adresseNom> dbl </ adresseNom > 
<versionNom> 8.1 <versionNom> 
</noeudNom> 
</ tnoeudNom > 
</tnoeud> 

(B3) 

< tnoeud ld= «162»> 

< tnoeudNom > 

<noeudNom> 

<groupeNom> SOL </groupeNom> 
<adresseNom> db2 </ adresseNom > 
<versionNom> 8.2 <verslonNom> 
</noeudNom> 
</ tnoeudNom > 
</tnoeud> 

Le nombre d'invocation du modele d'element correspond au nombre 
d'objets se reposant sur ce moddle MODELE. Ces trois blocs pnt pour meme 
facteur commun celui cree dans le fichier de desaiptlon. 

Selon une variante, un modele d'element peut contenir d'autres modeles 
d'elements. Ainsi, dans un fichier de configuration, on peut utiliser a I'interieur 
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d'une reference de modele d'element (par exemple « tnoeud ») une autre 
reference de modele d'elements. En effet, supposons qu'il existe dans le fichier 
de description DTD un modele d'element « tOracleNoeudNom » dont les 
elements definis sont 

■ I'element nomme groupeNom 

■ et I'element versionNom 

et dont I'element indefini est adresseNom. L'ecriture de ce modele d'element 
peut etre le suivant : 

< IMODELE tOracle8NodeName ELEMENT=noeudNom 

<groupeNom> Oracle </groupeNom> 

< IDEFINIR tOrocleDb ELEMENT=adresseNom> 

<verslonNom> 8.0 <versionNom> 

> 

De cette facon, lors de l'ecriture du fichier de configuration, on peut 
utiliser le modele « tOracleNoeudNom » pour definir I'element noeudNom. Le 
fichier de configuration s'ecrit alors de la facon suivante : 

< tnoeud ld=«123»> 
< tnoeudNom > 

< tOracle8NoeudNom> 

< tOracleDb> 

<adresseNom> dbO </adresseNom> 
</tOracleDb> 
</ tOracle8NoeudNom> 
</ tnoeudNom > 
</tnoeud> 

D'une maniere generate, la solution a pour objet un procede de creation, 
dans un systeme informatique, d'au moins un fichier de configuration d'au 
moins un objet materiel et/ou logiciel comprenant des parametres, ledit fichier 
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de configuration etant ecrit en utilisant un metalangage de description dont le 
format est independant du materiel et/ou logiciel a configurer, ce fichier de 
configuration incluant tout ou partie des parametres dudit objet et se reposant 
sur un fichier de description definissant des contraintes a respecter sur sa 
structure et sa syntaxe lors de son ecriture, caracterise en ce qu'il consiste, 
avant I'ecriture du fichier de configuration, a etendre le fichier de description 
par au moins un modele comprenant au moins un parametre decrit dans le 
fichier de description, et a valoriser tout ou partie des parametres de ce 
modele. 

Ensuite, lors de I'ecriture du fichier de configuration, la solution consiste 
a utiliser la partie du modele comprenant les parametres valorises comme 
facteur commun, et en ce que I'ecriture du fichier de configuration se limite a la 
valorisation des parametres ne comportant pas de valeur. 

Lors de la creation du modele, on a vu que la solution peut consister 
tout d'abord a regrouper les objets se reposant sur le meme fichier de 
description, ensuite a identifier les parametres dont la valeur est identique 
entre tous ces objets, et enfin e a valoriser ces parametres pour constituer un 
facteur commun dans ce modele. 

La solution consiste par exemple, lors de I'ecriture du fichier de 
configuration, si au moins deux objets se reposent sur le meme modele, a 
utiliser le facteur commun et a valoriser uniquement le restant des parametres 
de ce modele autant de fois qu'il y a d'objets se reposant sur ce modele 
d'element. 

Le langage utilise est extensible. Dans notre exemple, on a vu que la 
solution consiste a donner un nom pour identifier le modele dans le fichier de 
description, et en ce qu'il consiste a inclure dans le modele une reference du 
fichier de description, cette reference definissant les contraintes a respecter 
sur la structure et la syntaxe de ce modele. On a vu egalement que dans notre 
exemple, la solution consiste a introduire dans un modele deux mots cles 
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DEFINIR et DEFINI indiquant qu'un parametre est a definir (DEFINIR) ou est 
defini (DEFINI) dans ce modele. 

De preference, le langage du fichier de configuration est le langage 
XML, la solution consistant a prendre comme parametre un element et/ou un 
attribut d'un objet. Selon cette variante, la solution consiste a etendre le fichier 
de description par au moins un modele d'element comprenant au moins un 
parametre (element et/ou attribut) decrit dans le fichier de description, et a 
valoriser tout ou partie des parametres de ce modele d'element. De meme, la 
solution consiste a donner un nom pour identifier le modele d'element dans le 
fichier de description, et en ce qu'il consiste a inclure dans le modele une 
reference a un element du fichier de description, cette reference definissant les 
contraintes a respecter sur la structure et la syntaxe de ce modele. 

Enfin, on a vu que, sur requete d'une application utilisant le fichier de 
configuration, la solution peut consister a transmettre le facteur commun et les 
blocs resultant de la valorisation des elements indefinis. 

Enfin, il en resulte un fichier de configuration d'au moins un objet 
materiel et/ou logiciel comprenant des parametres, ledit fichier de configuration 
etant ecrit en utilisant un metalangage de description dont le format est 
independent du materiel et/ou logiciel a configurer, ce fichier de configuration 
incluant tout ou partie des parametres dudit objet et se reposant sur un fichier 
de description definissant des contraintes a respecter sur sa structure et sa 
syntaxe lors de son ecriture, characterise en ce que le fichier de description est 
etendu, et en ce que I'extension comprend au moins un modele. 

En conclusion, la solution offre de nombreux avantages. Un premier 
avantage est la simplification considerable de I'ecriture d'un fichier de 
configuration. En effet, les parametres definis etant valorises dans le modele 
d'element, I'ecriture du fichier de configuration se limite a la valorisation des 
parametres indefinis. En consequence, I'administrateur evite ainsi la repetition 
de parametres identiques entre objets. Le cout en temps d'ecriture et le risque 
d'erreurs d'ecriture lors de I'ecriture du fichier de configuration est largement 
reduit. De plus, I'introduction d'un facteur commun dans le modele reduit 
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considerablement la taille du fichier de configuration. Avantageusement, sur 
requete d'une application cliente, le systeme de gestion transmet ie fichier de 
configuration incluant le facteur commun du modele d'element et, pour chacun 
des objets, les parametres de ce modele d'element qui ont ete valorises lors de 
1'ecriture du fichier de configuration. La taille du fichier de configuration §tant 
reduit, le transfert de ce fichier s'effectue done plus rapidement. 
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REVEN DICATIONS 

1- Procede de creation, dans un systeme informatique, d'au moins un 
fichier de configuration d'au moins un objet materiel et/ou logiciel comprenant 

5 des parametres, ledit fichier de configuration etant stocke dans une memoire 
de stockage d'information et etant ecrit en utilisant un metalangage de 
description dont le format est independant du materiel et/ou logiciel a 
configurer, ce fichier de configuration incluant tout ou partie des parametres 
dudit objet et se reposant sur un fichier de description definissant des 

10 contraintes a respecter sur sa structure et sa syntaxe lors de son ecriture, 
caracterise en ce qu'il conslste, avant I'ecriture du fichier de configuration,. 

- a etendre le fichier de description par au moins un modele comprenant 
au moins un parametre decrit dans le fichier de description, 

- et a valoriser tout ou partie des parametres de ce modele. 

15 2- Procede selon la revendication 1, caracterise en ce qu'il consiste, lors 

de I'ecriture du fichier de configuration, a utiliser la partie du modele 
comprenant les parametres valorises comme facteur commun, et en ce que 
I'ecriture du fichier de configuration se limite a la valorisation des parametres ne 
comportant pas de valeur. 

20 3- Procede selon la revendication 1 ou 2, caracterise en ce qu'il 

consiste, lors de la creation du modele, a regrouper les objets se reposant sur 
le meme fichier de description et ensuite a identifier les parametres dont la 
valeur est identique entre tous ces objets, et en ce qu'il consiste a valoriser ces 
parametres pour constituer un facteur commun dans ce modele. 

25 4- Procede selon I'une des revendications 1 a 3, caracterise en ce qu'il 

consiste, lors de I'ecriture du fichier de configuration, si au moins deux objets 
se reposent sur le meme modele, a utiliser le facteur commun et a valoriser 
uniquement le restant des parametres de ce modele autant de fois qu'il y a 
d'objets se reposant sur ce modele d'element. 
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5- Procede selon Tune des revendications 1 a 4, caracterise en ce que 
le langage est extensible et en ce qu'il consiste a donner un nom pour identifier 
le modele dans le fichier de description, et en ce qu'il consiste a inclure dans le 
modele une reference du fichier de description, cette reference definissant les 

5 contraintes a respecter sur la structure et la syntaxe de ce modele. 

6- Procede selon Tune des revendications 1 a 5, caracterise en ce que 
le langage est extensible et en ce qu'il consiste a introduire dans un modele 
deux mots cles DEFINIR et DEFINI indiquant qu'un parametre est a definir 
(DEFINIR) ou estdefini (DEFINI) dans ce modele. 

10 7- Procede selon I'une des revendications 1 a 6, caracterise en ce que 

le langage est le langage XML, et en ce qu'il consiste a prendre comme 
parametre un element et/ou un attribut d'un objet. 

8- Procede selon la revendication 7, caracterise en ce qu'il consiste a 
etendre le fichier de description par au moins un modele d'6lement comprenant 

is au moins un parametre (element et/ou attribut) d6crit dans le fichier de 
description, et a valoriser tout ou partie des parametres de ce modele 

9- Procede selon la revendication 7 ou 8, caracterise en ce qu'il consiste 
a donner un nom pour identifier le modele d'element dans le fichier de 
description, et en ce qu'il consiste a inclure dans le modele une reference a un 

20 element du fichier de description, cette reference definissant les contraintes a 
respecter sur la structure et la syntaxe de ce modele. 

10- Precede" selon I'une des revendication 7 a 9, caracterise en ce qu'il 
consiste a inclure dans un modele d'etement au moins un modele d'element. 

11- Procede selon I'une des revendications 7 a 10, caracterise en ce 
25 qu'il consiste, sur requite d'une application utilisant le fichier de configuration, 

a transmettre le facteur commun et les blocs resultant de la valorisation des 
elements ind§finis. 
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